Development View

Introduction

Gradle is a large open-source project. The size and scope of the system necessitates the need for a clear way for new developers to the project to contribute to Gradle while ensuring that they can understand the code and make sure their changes will not have a butterfly effect on the rest of the code base.

The Development view focuses on several concerns: module organization, common processing, standardization of design, standardization of testing, instumentation, and codeline organization, as well as developer, production engineer and tester concerns.

Because of Gradle's modular design, this view is focused on the module, codeline organization and common processing concerns and how Gradle's source code is structured in order to ensure a good separation between modules.

This view will be of particular interest to developers looking to contribute to gradle as an open-source project but also for IDE developers who need to understand its structure and functionality. Additionally, it may be helpful to developers who will use gradle to better understand how to exploit its features.

Module Structure Model

The modules are organized into layers that group together modules which colaborate to perform a single functionality. An incoming arrow into a layer means that the layer uses the incoming module layer. Some layers share bidirectional arrows such as build and core.

Since Gradle is bootstapped, the modules are organized as subprojects of the gradle project. This allows for developers to easily add functionality to gradle by adding subprojects to the gradle project.

Explaination Of Layers

• Runtime Support Layer: The modules in runtime support layer can be consider as basic components to run Gradle. The modules' names start with 'base' provide some tasks and conventions that are common to most builds and add a structure to the build which will promotes consistency. The modules' names start with 'worker' will allow the running of pieces of work in the background. The other modules will provide support of java Virtual Machine, java process and the use of cache.

• File Layer: The modules in file layer will allow Gradle to interact with files like source files, file dependencies, reports and so on in an easy way.

• Core Layer: The core layer contains Gradle’s Project API. The Project API is available from build files and made up of 2 main interfaces: Project and Task. Project interface is main API we use to interact with Gradle. We can access all features of Gradle through this interface. Each task belongs to a project, the Task interface allows us to access each task instances.

• Build Layer: The modules in build layer are responsible for initializing plugins and tasks, also allowing plugins to receive information about the operations during a build. Some modules’ names contain 'build cache' which means they are responsible for a cache mechanism that aim to save time by reusing outputs produced by other builds. So, it can allow builds to fetch these outputs from cache when the inputs not change.

• Plugins Layer: The modules in plugins layer are responsible for managing plugin resolution and use, also assist with plugin development.

• Utility Layer: The modules in utility are responsible for launching Gradle, the Gradle command-line interface, doing composite-builds, the execution of command, producing report after each build, and dependency-management.

• Test Layer: The modules in test layer are responsible for testing. It contains Junit specific testing classes and support for general test suit. It also contains a library called 'test kit' that can help test plugins and build logic.

Common Design Model

Gradle uses several common designs including an extensive use of interfaces and a microkernal design pattern best exemplified through the integration of functionality in the form of plugins. Plugins can be built by third parties or the gradle team itself (although since gradle is open-source there is a bit of a grey line here). Additionally, most of the key parametric information for the gradle project is stored in the gradle.build file.

Common Processing Required

1. Use of third-party libraries
   • Plugins should be declared in the build script of the project before use. Gradle will automatically resolve and apply the correct plugins.

Standard Design

1. Initialization and recovery
   • The gradle project is built from the the build.gradle file. This file is used to build all other gradle files.
2. Processing configuration parameters
   • The build.gradle file contains the core parameters for the project, and is where core plugins can be applied, short names can be used.
   • The build file is written using either Groovy or Kotlin.
3. Use of third-party libraries
   • All plugins should be declared in the build script under ‘plugins’ using Groovy or Kotlin.
   • To apply a core plugin, short names can be used. To apply a community plugin from a portal, the fully qualified plugin id and version should be used.
   • Plugins can be declared with detailed information in the build script of the root project and just used in subprojects only with their name.

Standard Software Components

1. Internal and external interfacing
   • Gradle uses interfaces extensively to allow for easy polymorphism.
   • Specifically, in the subproject ‘core-api’, the package ‘org.gradle.api.plugins’ interfaces are used to get name of plugin from build script, find the correct version of plugin, check its validation, add t to the container, and finally apply the plugin to project.

Codeline Model

Gradle is a complex muiltilayered build integration tool that is rendered all the more complicated by its bootstrapped design. This model is designed to help make sense of its code and structure.

It is worth noting however, that this model focuses on the code structure pre-compilation. For each release gradle is complied using gradle, and thus the code structure will significantly change.

Source Code Structure

• One root project directory and a subprojects directory containing all the core functionalities described in the Module Structure Model.
• Each subproject has its own directory under subprojects.
• If a given functionality is too difficult to fit into one subproject or a series of subprojects are dependent on each other, they are broken into different subprojects whose names start with the same keyword, such as core and core-api.

Build, Integration, and Test Approach

• Gradle is bootstrapped, so as previously mentioned, new releases are complied using gradle itself.
• New features are integrated as new subprojects of the gradle-built "gradle project".
• Tests are performed using gradle tests built into gradle itself.

Release Process

• When the new version of Gradle is successfully built and tested, the new binary releases will be compiled using gradle. Then, the binary-only and complete version will be released with updated user manual, API Javadoc, DSL Reference, and Release Notes.

Configuration Management

• The source code is on GitHub. When someone wishes to contribute to Gradle, a new branch needs is created with a suitable name: developer name/project. After the changes are submitted, one of the core developers will review the pull request and make a decision on it. More information can be found here.

• Anyone who contributes to Gradle must also adhere to the Gradle Code of Conduct.